home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group95b.txt / 000080_icon-group-sender _Mon Jul 10 16:49:00 1995.msg < prev    next >
Internet Message Format  |  1995-09-18  |  12KB

  1. Received: by cheltenham.cs.arizona.edu; Mon, 10 Jul 1995 15:11:54 MST
  2. Message-Id: <9507101649.AA26606@ns1.computek.net>
  3. Mime-Version: 1.0
  4. Content-Length: 10945
  5. Content-Type: text/plain
  6. Content-Transfer-Encoding: 7bit
  7. Date: Mon, 10 Jul 95 16:49 CDT
  8. From: gep2@computek.net
  9. Subject: Snobol & System programming
  10. To: karczma@calvin.info.unicaen.fr
  11. Cc: icon-group@cs.arizona.edu
  12. X-Mailer: SPRY Mail Version: 04.00.06.17
  13. Errors-To: icon-group-errors@cs.arizona.edu
  14.  
  15. >Alors, tu as passe 9 ans a Paris. Je crois maintenant que tu as eu
  16. quelques occasions to begin to hate cars. Muy bien. 
  17.  
  18. Heheheh... claro que si, c'est dificil garer a Paris...  I've now lived in 
  19. numerous places with quite different approaches to mass/public/personal transit 
  20. and it's given me some hopefully-worthwhile observations on the subject.
  21.  
  22. >Still, you are younger than I, although your computing career might be a bit 
  23. longer. The point is that I have been for some time a theoretical physicist.
  24.  
  25. Fun stuff...
  26.  
  27. >I don't think there is a consensus on the merits/demerits of the explicit
  28. branching instruction as compared with while/select GodKnowsWhatElse. Do
  29. whatever you choose, but - please - there are two points which make it
  30. utterly impossible for me to adopt your attitude:
  31.  
  32. Fair enough, as long as you don't expect me to adopt yours...
  33.  
  34. >1. I teach programming languages, for many years already. Some structuring
  35.    methods are simply impossible to avoid if you try to convey the coding
  36.    strategies to the True Beginners. 
  37.  
  38. Rubbish.  People taught programming languages for DECADES before the arrival of 
  39. "structured programming concepts", and we did okay.
  40.  
  41. >  Perhaps for you a "break" is clumsier than :(DEHORS), 
  42.  
  43. It's not that it's necessarily clumsier, it's just a lot less obvious where 
  44. "break" transfers control to.  If you have a goto  :(DEHORS) and a label DEHORS, 
  45. then it's QUITE clear exactly where it's transferring to.  There's not the 
  46. slightest ambiguity, and you don't have to trust indenting, or count brackets or 
  47. something to confirm things.
  48.  
  49. >  but I assure you that polluting the lexical space of the
  50.    program with useless names is very harmful if you are a beginner. 
  51.  
  52. I claim that a 30-line text processing program in SNOBOL4 (and which maybe has a 
  53. dozen labels in it) is FAR, FAR clearer than a 3500-line program in C 
  54. (containing maybe a hundred function names) to do the same thing.  You seem to 
  55. think that labels are "pollution", I suggest that a lot of function names are 
  56. every bit as bad (and just imagine how many labels OR function names you'd need 
  57. in C to replicate the functionality of even a rather modest SNOBOL4 pattern 
  58. match statement).
  59.  
  60. >  For the
  61.    specialists, 'adultes et vaccines', comme les Francais used to say there
  62.    is no problem, but if you teach, then you finally get stuck inside this
  63.    particular philosophy which promotes modular programming. Snobol4 doesn't.
  64.    (OK, OK, there are structuring preprocessors. But I don't like disguises).
  65.  
  66. That's all ANY programming language/compiler is.  C programs end up finally 
  67. executing as GOTOs, just like SNOBOL4 or assembler or xBase or Pascal or Icon, 
  68. it doesn't matter WHAT your source code says.
  69.  
  70. >2. Have you ever tried to participate in a collective work, a program
  71.    written by a dozen persons, 20 pages of code each? Physicists do it
  72.    quite often. 
  73.  
  74. That's important when you write a 10,000 line program.  But note that VERY few 
  75. SNOBOL4 programs ever approach that length (the longest one I've written to date 
  76. is probably around 2000 lines).  It's not that they COULDN'T, of course... it's 
  77. just that they VERY rarely NEED TO.
  78.  
  79. >  There is a (small) probability that you finally get mad at ANY control
  80.    structures, not only at the jumps, but also at loops, computed gotos,
  81.    selects, etcaetera.  Then, you might think about hiding everything in
  82.    Objects, or convert to a Functionalist/Logical Religion (independently
  83.    of whether you are circumsized or not...).
  84.  
  85. Frankly, I am quite pleased when I find that the language simply PROVIDES the 
  86. features (and discipline) I need... intrinsically... that's the BEST way to 
  87. 'hide everything' and make the programmer's job as easy as possible.
  88.  
  89. >   Icon might be used as a functional language, Perl also. There are some
  90.    object-oriented structured at hand: Idol, or the whole OO-ref package
  91.    of perl5. You can choose better your style.
  92.  
  93. I'll be glad to ignore Perl, thankyouverymuch.
  94.  
  95. >Style c'est l'homme, so I do not plan to get you into my sect, nor to teach
  96. you anything. Anyway your attitude towards teachers seems to be ambiguously
  97. negative, 
  98.  
  99. I'm not down on teachers 'per se', I've had some VERY fine ones (as well as a 
  100. few REAL and TRUE dogs, I might add).  I think it's unfortunate, however, that 
  101. so many teachers will teach AWK and Perl and ignore things like SNOBOL4 (which I 
  102. personally still consider a VERY attractive language) and Icon.
  103.  
  104. >There are still some touchy points which you seem to disregard a bit. ....
  105. My problems are different, for example how to plug a program with textual output 
  106. through a named pipe to Gnuplot or Matlab to produce the high quality graphic 
  107. plots in a way transparent to the user. I can do it via Tcl or Perl. Where is 
  108. the power of Snobol4 in this context?
  109.  
  110. You can (at least -I- can) pipe input or output from SNOBOL4+ to other software 
  111. programs, (to the extent that anyone can under MS-DOS in any case).  One could 
  112. even write a loadable module to do sprites and fast pixel graphics from SNOBOL4+ 
  113. (although I've never felt the inclination/need to do so).  
  114.  
  115. Of course, the type of work YOU do and the type of work I do might be quite 
  116. different, so YMMV.  If you like Perl (and dislike SNOBOL4), then I can shake my 
  117. head in wonderment, but ultimately can't control a matter that's clearly a 
  118. question of your personal taste.
  119.  
  120. >I have to administrate a primitive, but multi-user database accessible through
  121. WWW. this is an educative game where all users might try to update this
  122. database concurrently. I need lockf's or other blessed fcntl protection
  123. mechanisms; to make on the fly some symbolic links, to seek index files etc.
  124. I cannot simply spawn an external process which would do that, because I have
  125. to keep a permanent grip on the file handles. I really need a primitive
  126. tool library. "C" has it. Perl as well. Where is the Snobol4 power? 
  127.  
  128. If you can do it in C, there is NO reason you can't do it from SNOBOL4+ too.  
  129. You can load a module under SNOBOL4+ written in assembler, that can do ANYTHING 
  130. that any other assembler routine called from another language can do.
  131.  
  132. >Can you give me an example of ONE CGI script written in Snobol4?
  133.  
  134. I haven't looked, quite honestly.  But I would assume that it's quite possible 
  135. to do one.
  136.  
  137. >B. Suppose you have a seminumerical problem to solve, a really nasty 
  138. asymptotic expansion problem (for example in computational physics). 
  139. The only *simple* way to program this is to use lazy semantics: streams or
  140. lazy lists. You have them for example in this "less powerful" Scheme. 
  141.  
  142. I didn't say that Scheme was "less powerful", I was talking about AWK and Perl. 
  143. So please don't put words in my mouth.
  144.  
  145. >You won't do them in Snobol4, and in Icon it is quite a task. Where is the 
  146. power?
  147.  
  148. And you'd write it in Perl, I expect.  Right?  If not, then what's your point?
  149.  
  150. >What about first-order continuations which you might use to emulate threads,
  151. or apply in general to simulation programs? In Scheme you can do it. 
  152.  
  153. Again, I'm not talking about Scheme.  I never mentioned the language, someone 
  154. else did.
  155.  
  156. Sure, you can point up specific programming tasks for which any given language 
  157. is less than ideal.  I never suggested that SNOBOL4 is perfect for everything.  
  158. But neither is ANY OTHER single language, either.  Heck, I can throw together a 
  159. quick business database enter/update/inquire/report application in less than an 
  160. hour or two in FoxPro that would take someone weeks to do in C, (OR Scheme OR 
  161. whatever).  Big deal.  That doesn't mean that SNOBOL4 isn't ideal for a great 
  162. many everyday programming tasks (and in fact, that's what I've found to be 
  163. true).
  164.  
  165. >I do not understand (please: although my English is very far from perfect,
  166. this is not the issue here) what do you mean by "people beating their noisy
  167. drum for a pitiful substitute...". 
  168.  
  169. I mean that there's a lot of people talking and making a big fuss about Perl and 
  170. Awk, and when you get right down to it, neither one of them is nearly as 
  171. interesting or useful (IMHO) as SNOBOL4 and Icon.
  172.  
  173. >I don't think that Perl protagonists are more conspicuous,
  174. more agressive, less polite than many others. 
  175.  
  176. They are certainly more conspicuous and more aggressive than the Icon and 
  177. SNOBOL4 fans are.  And it's NOT because Awk and Perl are more interesting, 
  178. useful, or powerful languages... it's clear that they are NOT.  When I was back 
  179. at Datapoint in R&D, I watched a friend and colleague... a REALLY NICE GUY... 
  180. get verbally attacked and repeatedly badmouthed by another programmer there.  
  181. The nice guy never rose up to defend himself (it wasn't his style) and 
  182. eventually people started to believe the loudmouth asshole.  So the nice guy 
  183. finally got fired.  Moral of the story?  Don't let the loudmouths win by 
  184. default, just because they make their presence felt more.  Speak up for the 
  185. little guys, the less-well-known, nicer alternatives.  Don't allow yourself to 
  186. get swept along in a tide, just because "everyone's doing it".
  187.  
  188. >You see, I am from Poland. 
  189.  
  190. Welcome.  I have many friends from (and still) there.
  191.  
  192. >...one of the major points of my personal philosophy (you see,
  193. I have really had un coup d'oeil on your home-page) is the tolerance. I would
  194. never permit myself to accuse anybody of using a "pitiful substitute" of a
  195. programming language, because I would ask myself first: what do i want
  196. really? To offend him? To convince him? To prove that I am better than he?
  197.  
  198. I primarily promote SNOBOL4 and Icon among my programming friends because I hope 
  199. that they will find those languages useful and helpful, and because teaching a 
  200. language to others (or interesting them in it) is a way to help keep a language 
  201. alive.
  202.  
  203. >Well, perhaps to make him think a bit. But is this a good way?
  204.  
  205. In the case of SNOBOL4 and Icon, yes I think it is.  I know that on FIDOnet and 
  206. Intelec, a lot of people learned about SNOBOL4 and Icon because of me, that 
  207. wouldn't have ever looked into them otherwise.  And I know several friends there 
  208. in Paris who nowadays use SNOBOL4 on at least an occasional basis that wouldn't 
  209. have ever learned about the languages otherwise.
  210.  
  211. One thing I have learned from the experience is that a lot of people cling 
  212. DOGGEDLY to their old [t]rusty programming tools.  You wouldn't believe how many 
  213. loons claim they prefer PDS Basic to something like SNOBOL4 or Icon.  And, I 
  214. must confess, for some (even quite lucrative) programming projects, I'll use 
  215. xBASE or even Databus as my preferred language... not because the language 
  216. itself is particularly elegant, but because for certain types of jobs, it simply 
  217. is the easiest, fastest, and most productive way to solve a problem and move 
  218. forward.
  219.  
  220. In any case, it's been interesting chatting with you about this stuff.  I'm 
  221. going ahead and copying the rest of the Icon group, in hopes that some of them 
  222. will find it interesting too.
  223.  
  224. Gordon Peterson
  225. http://www.computek.net/public/gep2/
  226.  
  227.